Erlebt Schengen eine „Renaissance“ oder geht es unter? Wird aus den vorübergehenden Wiedereinführungen von Binnengrenzkontrollen eine Dauereinrichtung?

Der „Schengen“-Raum ohne Binnengrenzen gehört zu den wichtigsten Errungenschaften der europäischen Integration. Sein Scheitern würde neben großen politischen Konsequenzen auch enorme finanzielle Kosten verursachen. Die von einer Reihe von Mitgliedstaaten zur Bewältigung der Flüchtlingskrise vorübergehend eingeführten Grenzkontrollen sind zwar zum Teil durch Ausnahmebestimmungen im Schengener Grenzkodex gedeckt, wären aber zB im Falle Österreichs und Deutschlands spätestens Mitte Mai 2016 wieder aufzuheben. Die Europäische Kommission versucht, durch einen eigenen „Fahrplan“, bis spätestens Ende 2016, das „Schengen-Dublin“-System wieder voll funktionsfähig zu machen. Daneben schlägt sie Reformen des „Gemeinsamen Europäischen Asylsystems“ (GEAS), ein eigenes „Einreise-Ausreise-System“ (EES) sowie die Einführung intelligenterer Informationssysteme für das Grenzmanagement vor. Die in der Übereinkunft mit der Türkei vom 18. 3. 2016 enthaltenen völkerrechtlichen und europarechtlichen Probleme und Unschärfen harren ebenfalls noch einer endgültigen Abklärung.The “Schengen Area”, with its absence of internal borders, is one of the foremost achievements of European integration. The Area’s collapse would cause, next to significant political consequences, vast economic implications. The temporary reintroduction of internal border controls by a number of Member States, due to the migration crisis, finds partial footing in provisions of the Schengen Borders Code. In the cases of Austria and Germany for example, said provisions would require that internal border controls be lifted by mid-May at the latest. Via a “Roadmap” and by the end of 2016 the European Commission aims to fully restore the “Schengen-Dublin” system’s functionality. In tandem, the Commission is proposing reforms of the “Common European Asylum System” (CEAS), the introduction of both an Entry Exit System (EES) and a so called Stronger and Smarter Information System for Border and Security management. The 18 March 2016 Agreement with Turkey contains problematic and blurry provisions regarding public international and Union law; these too remain to be clarified

Finanzielle Sanktionen bei Nichterfüllung von Urteilen des Gerichtshofs der EU

Gemäß Art 260 Abs 2 AEUV kann der Gerichtshof bei Nichtbefolgung eines verurteilenden Erkenntnisses finanzielle Sanktionen (Pauschalbeträge oder Zwangsgelder) verhängen, deren Berechnung nach feststehenden Kriterien zu erfolgen hat. Bei der Erstellung ihres Sanktionsvorschlags berücksichtigte die Kommission dabei stets – zusätzlich zur Schwere des Verstoßes und seiner Dauer – das Bruttoinlandsprodukt (BIP) des verurteilten Mitgliedstaates sowie die diesem im Rat der EU zugeteilten gewichteten Stimmrechte. Mit der Ersetzung des bisherigen Systems der Stimmenponderierung im Rat – für die Erreichung einer qualifizierten Mehrheit – durch das System der sogenannten „doppelten Mehrheit“ gemäß Art 3 des Protokolls (Nr 36) zum 1. April 2017 musste diese Berechnung aber angepasst werden, wie der Gerichtshof in seinem Urteil in der Rechtssache C-93/17 feststellte. Er berücksichtigt nunmehr, anstelle der gewichteten Stimmen im Rat, die Anzahl der Sitze, die jedem Mitgliedstaat im Europäischen Parlament zugewiesen sind. Darüber hinaus kumuliert der Gerichtshof seit seinem Urteil in der Rechtssache C-304/02 – entgegen der bloß alternativen Formulierung „oder“ in Art 260 Abs 2 AEUV – den Pauschalbetrag mit dem Zwangsgeld.Pursuant to Article 260 (2) TFEU, in the event of a Member State’s failure to comply with a judgment which condemns said State, the Court may impose financial penalties (lump sums or penalty payments) calculated in accordance with established criteria. When preparing its proposal for sanctions, the Commission takes into account the gravity and duration of the infringement; the gross domestic product (GDP) of the convicted Member State; and the weighted voting rights allocated to it in the EU Council. However, with the replacement of the existing system of vote-weighing in the Council, the methods for calculating sanctions also required adjusting, that is – for the attainment of a qualified majority – via the so-called "double majority", the system called for in Article 3 of the Protocol (No 36) had to be adjusted as per 1 April 2017. As stated by the Court in its judgment of Case C-93/17, the system now takes into account the number of seats allocated to each Member State in the European Parliament, instead of the weighted votes in the Council. Moreover, since its judgment of Case C-304/02 – and contrary to the word "or" in Article 260 (2) TFEU - the Court now cumulates the lump sum with the penalty payment

Las relaciones económicas y políticas entre las Comunidades Europeas y América Latina

Ponencia recogida en las actas de los Cursos de Derecho Internacional y Relaciones Internacionales de Vitoria-Gasteiz organizados por la Facultad de Derecho de la Universidad del País VascoA pesar de que a lo largo de los siglos, a través de una intensa cooperación política, económica y cultural hayan surgido algunos puntos de unión entre Europa y América Latina que serían dignos de ser documentados, en la actualidad no existe ningún trabajo que resuma la totalidad de estas relaciones. Con la entrada en escena de las Comunidades Europeas (CE) (1951/1957) cambia esta situación, ya que, éstas en su calidad de Unión de Estados, de Organización Internacional, se ponen en contacto con los países latinoamericanos y, en concreto, con sus asociaciones políticas y económicas.. Esta nueva característica conseguida en las relaciones entre Europa y América Latina me ha llevado a intentar hacer un balance de estas relaciones CEE-América Latina, que procuraré resumir en este Curso.Despite the fact that over the centuries, through intense political, economic and cultural cooperation have arisen some points of union between Europe and Latin America that would be worthy of being documented, at present there is no work that summarizes the totality of these relationships. With the entry of the European Communities (EC) (1951/1957) this situation changes, since, as the Union of States, of the International Organization, they get in touch with the Latin American countries and, in particular, with its political and economic associations. This new feature achieved in the relations between Europe and Latin America has led me to try to take stock of these CEE-Latin American relations, which I will try to summarize in this Course

Rehearsal: A Configuration Verification Tool for Puppet

Large-scale data centers and cloud computing have turned system configuration into a challenging problem. Several widely-publicized outages have been blamed not on software bugs, but on configuration bugs. To cope, thousands of organizations use system configuration languages to manage their computing infrastructure. Of these, Puppet is the most widely used with thousands of paying customers and many more open-source users. The heart of Puppet is a domain-specific language that describes the state of a system. Puppet already performs some basic static checks, but they only prevent a narrow range of errors. Furthermore, testing is ineffective because many errors are only triggered under specific machine states that are difficult to predict and reproduce. With several examples, we show that a key problem with Puppet is that configurations can be non-deterministic. This paper presents Rehearsal, a verification tool for Puppet configurations. Rehearsal implements a sound, complete, and scalable determinacy analysis for Puppet. To develop it, we (1) present a formal semantics for Puppet, (2) use several analyses to shrink our models to a tractable size, and (3) frame determinism-checking as decidable formulas for an SMT solver. Rehearsal then leverages the determinacy analysis to check other important properties, such as idempotency. Finally, we apply Rehearsal to several real-world Puppet configurations.Comment: In proceedings of ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI) 201

A mixed-method empirical study of Function-as-a-Service software development in industrial practice

Function-as-a-Service (FaaS) describes cloud computing services that make infrastructure components transparent to application developers, thus falling in the larger group of “serverless” computing models. When using FaaS offerings, such as AWS Lambda, developers provide atomic and short-running code for their functions, and FaaS providers execute and horizontally scale them on-demand. Currently, there is no systematic research on how developers use serverless, what types of applications lend themselves to this model, or what architectural styles and practices FaaS-based applications are based on. We present results from a mixed-method study, combining interviews with practitioners who develop applications and systems that use FaaS, a systematic analysis of grey literature, and a Web-based survey. We find that successfully adopting FaaS requires a different mental model, where systems are primarily constructed by composing pre-existing services, with FaaS often acting as the “glue” that brings these services together. Tooling availability and maturity, especially related to testing and deployment, remains a major difficulty. Further, we find that current FaaS systems lack systematic support for function reuse, and abstractions and programming models for building non-trivial FaaS applications are limited. We conclude with a discussion of implications for FaaS providers, software developers, and researchers

A mixed-method empirical study of Function-as-a-Service software development in industrial practice

Function-as-a-Service (FaaS) describes cloud computing services that make infrastructure components transparent to application developers, thus falling in the larger group of “serverless” computing mod- els. When using FaaS offerings, such as AWS Lambda, developers provide atomic and short-running code for their functions, and FaaS providers execute and horizontally scale them on-demand. Currently, there is nosystematic research on how developers use serverless, what types of applications lend themselves to this model, or what architectural styles and practices FaaS-based applications are based on. We present results from a mixed-method study, combining interviews with practitioners who develop applications and systems that use FaaS, a systematic analysis of grey literature, and a Web-based survey. We find that successfully adopting FaaS requires a different mental model, where systems are primarily constructed by composing pre-existing services, with FaaS often acting as the “glue” that brings these services to- gether. Tooling availability and maturity, especially related to testing and deployment, remains a major difficulty. Further, we find that current FaaS systems lack systematic support for function reuse, and ab- stractions and programming models for building non-trivial FaaS applications are limited. We conclude with a discussion of implications for FaaS providers, software developers, and researchers

Enforcement of entailment constraints in distributed service-based business processes

Abstract Context: A distributed business process is executed in a distributed computing environment. The service-oriented architecture (SOA) paradigm is a popular option for the integration of software services and execution of distributed business processes. Entailment constraints, such as mutual exclusion and binding constraints, are important means to control process execution. Mutually exclusive tasks result from the division of powerful rights and responsibilities to prevent fraud and abuse. In contrast, binding constraints define that a subject who performed one task must also perform the corresponding bound task(s). Objective: We aim to provide a model-driven approach for the specification and enforcement of task-based entailment constraints in distributed servicebased business processes. Method: Based on a generic metamodel, we define a domain-specific language (DSL) that maps the different modeling-level artifacts to the implementation-level. The DSL integrates elements from role-based access control (RBAC) with the tasks that are performed in a business process. Process definitions are annotated using the DSL, and our software platform uses automated model transformations to produce executable WS-BPEL specifications which enforce the entailment constraints. We evaluate the impact of constraint enforcement on runtime performance for five selected service-based processes from existing literature. Results: Our evaluation demonstrates that the approach correctly enforces task-based entailment constraints at runtime. The performance experiments illustrate that the runtime enforcement operates with an overhead that scales well up to the order of several ten thousand logged invocations. Using our DSL annotations, the user-defined process definition remains declarative and clean of security enforcement code. Conclusion: Our approach decouples the concerns of (non-technical) domain experts from technical details of entailment constraint enforcement. The developed framework integrates seamlessly with WS-BPEL and the Web services technology stack. Our prototype implementation shows the feasibility of the approach, and the evaluation points to future work and further performance optimizations

Fifty Shades of Grey in SOA Testing

Abstract-Testing is undisputedly a fundamental verification principle in the software landscape. Today's products require us to effectively handle and test huge, complex systems and in this context to tackle challenging traits like heterogeneity, distribution and controllability to name just a few. The advent of ServiceOriented Architectures with their inherent technological features like dynamics and heterogeneity exacerbated faced challenges, requiring us to evolve our technology. The traditional view of white or black box testing, for example, does not accommodate the multitude of shades of grey one should be able to exploit effectively for system-wide tests. Today, while there are a multitude of approaches for testing single services, there is still few work on methodological system tests for SOAs. In this paper we propose a corresponding workflow for tackling SOA testing and diagnosis, discuss SOA test case generation in more detail, and report preliminary research in that direction